1. Technical Field
The present disclosure relates to data processing and, more particularly, to systems and methods for hazards analysis.
2. Discussion of Related Art
In today's expanding global market, knowledge and the ability to apply it provide an important advantage. Increasingly, product features are analyzed to determine the cost of implementation, to provide specifications for manufacturing and/or software development, and to provide a framework for developing a test plan and test cases. Use case analysis is a widely used methodology for performing product or system analysis. Use case analysis is a means of modeling the requirements of the product or system to be built.
The use case provides one or more scenarios describing a set of possible sequences of interactions between systems and users called actors performing tasks in a particular environment and related to a specific goal or function. Use case actors may be end users or other systems. The relationships among the use cases and the actors are often diagrammed using the Unified Modeling Language.
The Unified Modeling Language (UML) is a general-purpose modeling a language for specifying, visualizing, constructing, and documenting the artifacts of a system-intensive process. It can be used for business process modeling, systems engineering modeling, representing organizational structures, as well as software development. UML includes a standardized graphical notation used to create an abstract model of a system, referred to as a UML model. UML models may be serialized in XML Metadata Interchange (XMI). The XMI format is a standard for exchanging metadata information via XML (extensible markup language) between modeling tools based on the UML.
Products and services are regularly required to have an associated hazards analysis for regulatory purposes. Where there is a use case or UML model, it is helpful that the hazards analysis be integrated into the modeling framework. However, a hazards analysis facility should remain sufficiently independent of a modeling environment such that documentation can be done even if there is no associated UML model.
A hazard may result in finding additional system or product requirements to mitigate the hazard. These requirements must be documented. For example, the hazard should trace to the use case (scenario) with which it is associated. That is, the requirements derived from a study of the hazard should trace back to the hazard. In addition, the requirements derived from the hazard must trace to/from other requirements that are impacted or that impact on the hazard-related requirement.
Conventional hazard analysis techniques that focus on discrete failure events consider faults likely to lead to failures based on physical effects. In these event-based techniques, hazard analysis consists of identifying the failure events that can lead the system to a hazardous state. These failure events are usually organized into causal chains or trees. Examples of event-based hazard analysis techniques include Fault Tree Analysis (FTA) and Failure Modes and Effects Criticality Analysis (FMECA).
Many systems evolve to accomplish changing objectives or to adapt to environmental pressures or changing customer tastes. A primary design goal may be to ensure that the safety constraints continue to be enforced as changes occur throughout the life of the system. Accidents in complex systems, for example, often involve the migration of the system toward an unsafe or unstable state. Since traditional hazard analysis techniques view systems as static, hazards resulting from a migration of the system to an unsafe state can be overlooked. Traditional hazard analysis techniques may do a poor job of handling complex human decision making, organizational and managerial aspects of systems, and the adaptation of systems over time.